It is known that the term “method port” refers to an IDL (interactive data language) of CORBA (a common object request broker architecture), which allows a component to access specific methods through a class.
Generally, in CORBA, a skeleton code is generated by an IDL compiler and methods are directly implanted on the code, or a code cooperating with separately implemented methods are written in the skeleton code to define an interface between software components. However, in this case, a user needs to newly create a skeleton code by the IDL compiler to correct the written code when the interface definition is changed.
To solve the above problem, a technique has been proposed, which separates an interface class from an actual data processing class under the assumption that each port functions as a transmission terminal for sending and receiving messages. This technique is implemented in a manner that CORBA is used as a transmission mechanism, data transmission is made by MsgPortClass, connection between modules is established by ConnPortClass, and each interface is defined by IDL, thereby avoiding change of a data processing part upon change of interface definition or change of an interface processing portion upon change of the data processing portion which is the defect of CORBA. However, this technique cannot be applied to cases where middlewares other than CORBA are employed.
As another proposal, there is a technique of dynamically establishing a connection between software components that are in operation by a dynamic connection manager. This technique is directed to a communication technique between respective ports of components operated in a software communication architecture (SCA) based system. More specifically, the technique allows the dynamic connection manager to execute a mapping between ports by using XML to properly cope with component down or replacement at run-time. This technique, however, has a shortcoming that lots of changes on code should be done upon change of interface definition because the interface and the data processing part are not separated from each other.
Further, the two techniques described above have a drawback that a developer needs to separately implement interfaces to access methods offered by software components although they have a same function, when accesses made by variety interfaces such as an interface from a manager, an interface from a user, and an interface from a monitor.